Subject: Open Item List for Release 1 DLSw Standard

From: "Steve Klein (254-5623)" <[email-masked]>
Date: Mon, 6 Jun 94 07:38:48 EDT

Please excuse the tardiness of this note.  The AIW mail exploders
were experiencing technical difficuluties last week.

Ok, here is is, the open Connect items to nail down for the first
release of our standard.  I noted additions from the original list
with <<<<<<.

Open Items:
- consensus on SDLC scenarios for general 'feel' of how SDLC will work
- impact of SDLC to DLC events
- impact of SDLC on FSMs
- support for non-activation XIDs (any opposition to this?)
- propagation of Routing Control Field Largest Frame bits in SSP messages
- propagation of Routing Control Field Broadcast  <<<<<< added by
  Indicators in SSP messages                      <<<<<< G. Pandian
- including in the CANUREACH message the frame (TEST, XID) that generated
  it
- agreement on local retries of DLC frames (absorption of retries on
  origin side with local retries on target side)
- obsolete ENTER_BUSY, EXIT_BUSY, TEST_CIRCUIT_REQ, TEST_CIRCUIT response
  commands in SSP Message Type Table and remove them from the FSMs
  (since it looks like these messages are not required for the standard,
   leave them as optional messages that could be supported if desired)
- nail down when Data Link Correlators, Port IDs,  <<<<<< added by
  and Transport IDs may vary during circuit setup  <<<<<< Paul
- support for 15 and/or 16 byte NETBIOS names      <<<<<< Brittain

The next checkpoint I would like us to shoot for is to have all of the
smaller open issues (everything not involving SDLC) resolved by June 17
so we have a good week to look over any related FSM changes before the
AIW.  I will take a look at all of the SDLC correspondence and try to
sort out where there is agreement and where there are differences in
opinion.

I will be sending out the FSM changes related to separation of topology
and circuit establishment, circuit start collisions, and non-activation
XID support later today.  I have been reviewing them with the IBM DLSwers
and have been refining them this week.

It looks like we have started discussion on the broadcast indicator being
propagated in SSP messages.  Please post any other opinions related to
this subject as soon as possible.

Steve

---

From: Lakshman Garikapaty <[email-masked]>
Date: Tue, 7 Jun 94 07:10:51 PDT

>  if message_type is  dataframe then message_len is message_len passed in
 >  the dls msg else message_len is control_message_len which is equal to 72
 
 oops i missed the message length in control message:

   The algorithm should be:

  Send 0 in the message length if there is no data associated with the control
message. Read the message length first and if it is control message and 0 len
then the total message length is 72 else calculate the message length based on
message type.